Our quest to transition to model-based systems engineering – and the larger transformation of the development lifecycle to digital engineering – centers on moving from relatively low-fidelity documents to higher fidelity, richer representations. In doing so, we can move from the ambiguity of documents to digital clarity, allowing us to better analyze and engineer systems. But too often we find ourselves lost in the diagrams and representations when the real meaning is in the metamodel.
To successfully engineer a system requires that we truly align on the what and the why with clarity. The team must have a shared understanding of the problem, the governing architecture, and the solution. As Stanley McChrystal frames in Team of Teams, “functioning in an interdependent environment requires that every team (member) possess a holistic understanding of the interaction between all the moving parts.” Without that shared understanding at the human level, team members cannot be empowered to make good decisions.
Likewise, as we seek to transform the engineering value chain from a series of disjoint silos to connected digital engineering, we must have clarity in the underlying concepts. While humans may be capable of accommodating some degree of ambiguity when mapping concepts, we don’t have the same luxury in engineering our connected environments. For engineering to proceed smoothly, we must ensure that the concepts are mapped with precision across the engineering lifecycle so that data flows seamlessly and analysis proceeds without error.
Whether dealing with humans or software, the clarity we need is not in the diagrams. Diagrams and other representations are essential tools in understanding and analyzing from multiple perspectives, but they lack the necessary depth of semantic meaning and rigor. The digital clarity we seek resides in the metamodel underpinning our processes, methods, and tools. Without the shared metamodel, we lack the framework for connected engineering or shared understanding. Without the right metamodel, we find ourselves reliant upon implicit meaning and hope rather than explicit definition and rigor.
So what is a metamodel? For our purposes, it can be considered an explicit representation of the information necessary to engineer a system. It is a framework within which the fundamental concepts and their interrelationships are defined with clear semantic meaning. (It is not enough to define the concepts in isolation.) For example, when the word “requirement” is used, that concept must be defined and understood. Likewise, when noting that a function has been “allocated to” a subsystem, there must be clear semantic meaning attached. While that may sound trivial, consider the meaning of the word “function” to a systems engineer, a software engineer, and an electrical engineer. While the overriding concept may be similar, the semantic differences to each individual and each discipline are easily enough to create ambiguity and all the unintended consequences that follow.
So what about SysML? SysML is still a valuable part of the systems engineer’s toolkit, a useful set of representations for communicating systems concepts with those trained in the notation. The problem is that SysML as disjoint diagrams or SysML with a basic data dictionary is not enough. It is SysML underpinned by a well-designed metamodel suitable for engineering systems that truly brings value to the practitioner and the enterprise. The nine SysML diagrams then become standardized representations for specific viewpoints and subsets of information while the engineered metamodel provides the requisite semantic underpinning and meaning. (To learn more about this concept, see this 3-minute video or take a deep dive into the white paper One Model, Many Interests, Many Views.)
The SysML community has identified the lack of a defined metamodel in SysML 1.5 as a key issue to address in SysML 2.0, and closing that gap will be part of the SysML 2.0 specification currently projected for November 2020. Developing a systems engineering metamodel is about more than simply capturing the information in a semantically useful manner suitable for human and machine consumption. It becomes a valuable tool for assessing both what you know and what you don’t about both problem and solution. A good metamodel will reflect far more than simply the outcome of systems engineering activities. It will reflect the design journey, exposing thinking, alternatives, decisions and rationale in real time, enabling collaboration before bad decisions are embedded in design.
And the metamodel for engineering systems is about far more than model-based, digital, or even our systems of interest. It advances the maturity of systems, making explicit the necessary information we seek, the interrelationships between our processes and methods, and the necessary learnings as we capture heuristics, design patterns, and principles.
Many contributors are working to develop the right metamodel as part of SysML 2.0, and time will tell what emerges. But what do we do today? We certainly can’t press the pause button on all systems engineering efforts until SysML 2.0 is released.
Let’s look at a few options.
- You could proceed without a metamodel, but in doing so you are at risk of slipping into diagram-based systems engineering. You may replace documents with drawings, but you will lack the semantics and digital clarity required to engineer complex systems. In place of a defined metamodel with provenance, you may struggle with looser concepts at the whim (or in the head) of the designer. Unfortunately, I have heard countless stories of this challenge across industry as organizations have stumbled into this state and realized that they lack the shared understanding and the interoperability they sought – even amongst different systems engineers working within the same tool.
- You could develop your own metamodel. The issue here is the difference between a good metamodel and just any metamodel. Developing a metamodel is actually a rather easy task. Web-based ontology editors make it even easier. However, developing a good metamodel is difficult. It requires not only expertise in systems engineering, but also similar expertise in knowledge representation and semantic science. It is something best accomplished by a small team who can argue and debate the concepts from multiple perspectives with the results vetted by a larger team based upon their collective experience and then proven on multiple projects. Good metamodels don’t emerge fully formed, and they are rarely reverse engineered into a tool. Instead, they are proven out over time with a legacy of practical success.
- The better path is to adopt and tailor an existing metamodel for engineering systems. While there is not a singular, agreed-upon metamodel that underpins our practice, there are several which reflect years of research and practical application. None will perfectly represent the domain-specific aspects of your project, but each can capture the essential aspects of systems engineering and is extensible to your needs. AP-233 was developed by INCOSE in the early 2000s and became a standard, though attention shifted to other efforts; AP-233 was never widely adopted. Bill Schindel, leader of INCOSE’s Patterns Working Group, has developed the S* metamodel based upon years of experience and application. Vitech has its metamodel derived from foundational TRW work on ballistic missile defense in the late 1960s with 15 years of further research funded by the U.S. Army. This metamodel has continued to evolve based upon 50 years of practical application, insights from DoDAF and SysML, as well as our own innovations. We are happy to share this model with those interested. (A lightweight graphical representation is present in the One Model, Many Interests, Many Views white paper.)
Whether you are interested in effective communication, shared understanding across a project team, or connecting the engineering value chain to implement digital engineering, it’s about the data, not the diagram. It’s about the information, not the representation. Traceability, configuration management, big data, comprehension, alignment, portability, mappings, defensibility, what ifs, FMECA, risk, post-mortems (and learning), and more all key off the information and the semantic meaning. If we truly want digital clarity to enable the engineering of complicated and complex systems, our journey must include a well-engineered metamodel. The metamodel – not the drawing – is where understanding begins, interrelationships become explicit, and meaning resides. If we truly want clarity, understanding, and connected engineering, it’s time to stop talking about the drawings we want and start talking about the information we need.
